Thick and Thin Logical Volumes
There are two types of logical volumes—thick volumes and thin volumes.
A first perspective of these terms may refer to internal allocation issues. Under this perspective, the distinction is a purely internal one, and it is transparent to the user. In terms of internal space accounting, at the time of creation of the volume, the space devoted to the volume is taken into account, so that when all available space has been distributed among created volumes and snapshot pools, no new volumes may be created. This is true for both Thick and Thin volumes. The user is told that a volume of the chosen size is available to him.
The difference is that thick volumes are also fully allocated on the disks at the time of creation. When data is written to thick volumes it is stored in the disk locations that were allocated at the time of creation. Disk space allocated to pools is used as the need arises, but the overall space allocated to a pool is allocated from the outset. Thin volumes are taken into account for space accounting, but no specific allocation is done on the disk in advance. Accordingly, a creation of a thin volume may involve allocating a virtual portion of the pool for storing the thin volume—without actually allocating a physical space.
Only when data is written to the logical volume (actually on the destage step) the specific location on the disk is chosen. Under this approach the use of the thin volumes is that if the maximal total capacity of the system is TC, but the disks currently installed cover only a part of that total capacity, say PTC, then the total storage capacity may be distributed among the users from the beginning, and the actual physical capacity will be added as the need arise. But it will never be the case that more storage capacity is allowed to users than can possibly be contained in the system (a situation that could create a conflict—since the user is expecting to have a certain capacity and that will not be the case when he needs it).
A second perspective of these terms views thick volumes and thin volumes as an external allocation issue. Under this perspective, the idea is that more space may be assigned to users than actually there is in the machine. If a user is assigned a thin volume Vj with size VSj, then the system does not warrant that when the space is needed, if this is a thin volume, all the space VSj will indeed be available.
In general, in a system with static allocation it is more natural to define thick volumes as the standard and add special mechanisms for defining thin volumes. In systems with dynamic allocation (or log write, or write-anywhere) the natural thing is to define thin volumes as basic and then add special mechanisms for the thick volumes.
Space Management of a Storage System that Supports Snapshots
In a storage system with snapshots it is necessary to define a storage space devoted to storing the data deltas of the snapshots of a given volume or group of volumes. This is done typically in terms of “storage pools”. A consistency group C of size SPC may include logical volumes (volumes) V1, . . . VJ, with sizes VS1, . . . VSJ.
The storage system can include a pool for the consistency group C, which is storage space of size SPCS.
Each volume may have snapshots SNj(i) wherein j is the identifier of the volume, and i is a running index of snapshots (points in time) for the given volume. According to the standard procedures for handling snapshots, once the snapshot is created and the volume associated with the volume is modified, then “data deltas” of data associated with certain snapshots have to be stored, and this is done with the help of the pool.
The pool helps define the amount of physical storage space that is devoted to snapshots for the group C. Inasmuch as data deltas are being created, the storage space assigned to the consistency group C will be depleted (and space may be recovered if snapshots are deleted).
At any point in time, it is possible that when a volume is overwritten and a data delta associated with a certain snapshot has to be stored, there is no further space in the pool to store it.
In such cases, different vendors follow different strategies, which depend on either (1) the internal functioning of the system and the advantages or disadvantages that its architecture provides in terms of quickly or slowly deleting snapshots or volumes or (2) policies that relate to what the vendor is willing or unwilling to responsibly warrant to the user. In general these strategies may comprise one of the following: (1) not allowing the completion of the write command; (2) deleting data associated with one of the existing snapshots according to some policy defined in advance (e.g., data associated with the oldest, or the newest, or the largest, or the smallest, etc. snapshot); (3) providing some mechanism that attempts to identify in advance potentially dangerous situations of space depletion and taking some measure to counter them.
Existing mechanisms for space management in a storage system with snapshots may yield unexpected situations of space depletion that will arise at time of critical performance thus creating problems for the user.
It is necessary to develop mechanisms that will prevent such situation, such as for example by means of warranting that snapshots of a certain size will never give rise to such problematic situations, i.e., that write requests directed at the volume will not fail because there is no space for additional data deltas related with the snapshot.